Summary

_submit_async_operation (the helper behind submit_async_consolidation,
submit_async_retain, submit_async_file_retain, and
submit_async_refresh_mental_model) always INSERTs into async_operations,
which has an FK to banks(bank_id). If a caller submits for a bank that
doesn't exist — race against a concurrent bank deletion, or an integration
that derives bank IDs and submits before the bank's CREATE has been
issued — the INSERT raises asyncpg.exceptions.ForeignKeyViolationError.

The FastAPI endpoints wrap submit calls in a generic except Exception and
return HTTP 500 with the FK violation in the detail. This is a client-side
error misclassified as a server fault. It pollutes 5xx error-rate metrics
with what should be 404s, and exposes asyncpg internals to API consumers.

Fix

Add a bank-existence precheck at the top of the INSERT path in both branches
of _submit_async_operation:

• dedupe_by_bank=True already runs
  SELECT 1 FROM banks WHERE bank_id = $1 FOR NO KEY UPDATE for
  serialization (issue Consolidation: large backlogs don't drain to completion; concurrency decays to ~1 despite WORKER_CONSOLIDATION_MAX_SLOTS #1842). Switch it from conn.execute() to
  conn.fetchval() so the returned value gates existence — same SQL,
  same lock semantics, but the rowcount becomes observable. If
  bank_exists is None, raise OperationValidationError(404).

• dedupe_by_bank=False (scoped consolidation submits, etc.) had no
  lock and no check; add a plain SELECT 1 FROM banks for existence only.
  Same OperationValidationError(404) on miss.

The FastAPI endpoints' existing handler already converts
OperationValidationError to HTTPException(status_code=e.status_code, detail=e.reason) — no API-layer changes needed.

Test plan

hindsight-api-slim/tests/test_async_submit_bank_not_found.py:

• test_consolidation_submit_on_missing_bank_raises_validation_error —
  unscoped submit on a non-existent bank asserts OperationValidationError
  with status_code == 404 and bank ID in the reason.
• test_scoped_consolidation_submit_on_missing_bank_raises_validation_error —
  same but with observation_scopes set (takes the dedupe_by_bank=False
  branch).
• test_graph_maintenance_on_missing_bank_short_circuits — pins the
  pre-existing behaviour that submit_async_graph_maintenance returns
  {"operation_id": None, "no_work": True} before reaching the INSERT
  (its own queue precheck already covers the FK case).

Regression sweep on adjacent suites — 59/59 passing:

• test_async_submit_bank_not_found.py (new) — 3
• test_consolidation_submit_atomic_dedup.py — verifies dedup lock semantics
  (lock behaviour was the only thing I worried about touching). All 4 pass.
• test_consolidation_retry_dedup_by_bank.py
• test_consolidation_silent_requeue_failure.py
• test_consolidation_scope_parallelism.py
• test_op_cancellation.py
• test_async_batch_retain.py
• test_async_retain_tags.py

ruff check + ruff format clean. Pre-commit hooks pass.

Compatibility

• Postgres: no behavior change for normal flow (bank exists). The
  FOR NO KEY UPDATE lock is unchanged.
• Oracle: same — the FOR NO KEY UPDATE -> FOR UPDATE rewrite is
  identical, and the existence check is a plain SELECT 1.
• API contract: existing 500 path on a missing-bank submit becomes a 404.
  Callers that were relying on the 500 (unlikely — it surfaced asyncpg
  internals) should already be retrying or surfacing the error.